Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support hiding window title when using vertical tab strip #15523

Merged
merged 12 commits into from
Oct 25, 2022

Conversation

sangwoo108
Copy link
Contributor

@sangwoo108 sangwoo108 commented Oct 19, 2022

Resolves brave/brave-browser#25473
Resolves brave/brave-browser#25757

Add a tab context menu to hide window title when vertical tab strip is enabled. When hiding window title, we can claim title area so that users can use taller contents area.

  • On Mac and Window, toolbar will take the title area.
  • On Linux, title area will be as short as possible
    • can't overlay caption buttons on toolbar for now.

Also, we should make it easy to move window when hiding window title as there's almost no non-client area. Thus, enable dragging windows by dragging toolbar area.

Windows glass frame

no title

image

with title

image

Windows opaque frame

with title

image

no title

image

Mac

With title

image

no title

image

Linux

With title

image

No title

image

Submitter Checklist:

  • I confirm that no security/privacy review is needed, or that I have requested one
  • There is a ticket for my issue
  • Used Github auto-closing keywords in the PR description above
  • Wrote a good PR/commit description
  • Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
  • Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
  • Checked the PR locally: npm run test -- brave_browser_tests, npm run test -- brave_unit_tests, npm run lint, npm run gn_check, npm run tslint
  • Ran git rebase master (if needed)

Reviewer Checklist:

  • A security review is not needed, or a link to one is included in the PR description
  • New files have MPL-2.0 license header
  • Adequate test coverage exists to prevent regressions
  • Major classes, functions and non-trivial code blocks are well-commented
  • Changes in component dependencies are properly reflected in gn
  • Code follows the style guide
  • Test plan is specified in PR before merging

After-merge Checklist:

Test Plan:

Manual

  • When using vertical tab strip, there should be a context menu item to show/hide window title
  • When toggling window title state, window title visibility should be changed
  • When hiding window title, non client area should be at minimum size.
  • Dragging toolbar will moving the window

Automated

VerticalTabstripBrowserTest.WindowTitleVisibility.Toolbar
BraveNonClientHitTestHelperBrowserTest.WindowTitle

@github-actions github-actions bot added the potential-layer-violation-fixes This PR touches a BUILD.gn file with check_includes=false label Oct 19, 2022
@sangwoo108 sangwoo108 marked this pull request as ready for review October 20, 2022 05:56
@sangwoo108 sangwoo108 requested a review from a team as a code owner October 20, 2022 05:56
@sangwoo108 sangwoo108 force-pushed the sko/vtab-toolbar branch 5 times, most recently from 5ad9948 to 74512c2 Compare October 20, 2022 14:49
</if>
<if expr="use_titlecase">
<message name="IDS_TAB_CXMENU_BOOKMARK_ALL_TABS" desc="In Title Case: The label of the tab context menu item for creating a bookmark folder containing an entry for each open tab.">
Bookmark All Tabs...
</message>
<message name="IDS_TAB_CXMENU_SHOW_TITLE_BAR" desc="The label of the tab context menu item for showing window title when vertical tab strip is enabled.">
Show Window Title
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's kinda annoying how we have to do this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, indeed. I wish we could automate casing

Copy link
Contributor

@fallaciousreasoning fallaciousreasoning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, might be worth trying to add some browser tests though. I'm excited for this feature!

Edit:

I just tried changing the theme to Use GTK - it crashes the latest nightly when vertical tabs are enabled. On your branch it does nothing (even when vertical tabs are disabled). Might be worth looking into.

Also, playing around with the setting on Linux it's quite hard to drag the window around now
image

And I think the window icons come a bit out of the frame

app/brave_generated_resources.grd Outdated Show resolved Hide resolved
browser/ui/views/frame/brave_browser_frame_mac.mm Outdated Show resolved Hide resolved
browser/ui/views/frame/brave_glass_browser_frame_view.cc Outdated Show resolved Hide resolved
browser/ui/views/tabs/features.cc Outdated Show resolved Hide resolved
browser/ui/views/tabs/features.h Outdated Show resolved Hide resolved
@simonhong
Copy link
Member

On linux, I always enable system title and borders. Title is located in the center of title bar.
and that center position looks good for me. It's just a suggestion :)
image

@sangwoo108
Copy link
Contributor Author

sangwoo108 commented Oct 21, 2022

@fallaciousreasoning

it crashes the latest nightly when vertical tabs are enabled

Err, it might be due to overlay mode. Let me check it out.

Also, playing around with the setting on Linux it's quite hard to drag the window around now

It seems HTCAPTION things are not working as expected on Linux. @simonhong Are you using linux too?

And I think the window icons come a bit out of the frame

This shouldn't happen :( The height looks incorrect when using GTK theme.

Also, playing around with the setting on Linux it's quite hard to drag the window around now

It seems your version uses caption button based on vector icon, which I didn't expect:( 18 seems to be too short for it. Let me dig this deeper. Anyway, I think dragging with toolbar area should work now.

@sangwoo108
Copy link
Contributor Author

sangwoo108 commented Oct 21, 2022

@simonhong

On linux, I always enable system title and borders. Title is located in the center of title bar.

Yeah, I totally agree. I'm considering that too but window title implementation for each platform differs so I think I could do it as a follow-up.

@sangwoo108 sangwoo108 force-pushed the sko/vtab-toolbar branch 7 times, most recently from 98bcbd7 to 5336bd8 Compare October 23, 2022 07:15
@sangwoo108
Copy link
Contributor Author

might be worth trying to add some browser tests though

Now we have browser tests too and other things are addressed, I think. @simonhong @fallaciousreasoning Do you mind taking another look?

Copy link
Contributor

@fallaciousreasoning fallaciousreasoning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

return overridden_window_title_visibility_.has_value(); \
} \
bool overridden_window_title_visibility() const { \
return overridden_window_title_visibility_.value(); \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we do a .value_or(false) here? It's not obvious that the method will crash if you don't check has_overridden_window_title_visibility first.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not obvious that the method will crash

I thought it'd crash, but it seems it's close to undefined behavior. I think it's better to let it crash to detect problems for some cases, and this is the case. And also I intentionally didn't use .value_or() here, because when there's no overridden visibility, we should use WidgetDelegate::ShouldShowWindowTitle() to know about the default visibility.

Now I find it that DCHECK(has_overriden_visibility()) << "Use WidgetDelegate::ShouldShowWindowTitle()" is more explicit and better, thanks to your comment.

chromium_src/ui/views/widget/native_widget_mac.h Outdated Show resolved Hide resolved
Copy link
Contributor

@fallaciousreasoning fallaciousreasoning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@simonhong simonhong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++ 👍🏼

Copy link
Member

@goodov goodov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

few nits + can you please double-check that new chromium overrides are fine without VerticalTabs enabled? to make sure we didn't break some edge case when the feature is off.

if (const gfx::ImageSkia* image = tp->GetImageSkiaNamed(image_id))
width += image->width();
}
return {0, width};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are all of these numbers work correctly with different OS-level screen scale?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it looks so. Both seems to be DIP.

return GlassBrowserFrameView::GetTopInset(restored);
}
int BraveGlassBrowserFrameView::NonClientHitTest(const gfx::Point& point) {
if (auto res = brave::NonClientHitTest(browser_view(), point);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this check VerticalTabs feature?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'd better to support this for others too. brave/brave-browser#25757

Copy link
Contributor Author

@sangwoo108 sangwoo108 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you please double-check that new chromium overrides are fine without VerticalTabs enabled?

Yep sure. Confirmed that there's no crash and frame view works well without the flag.


I found that one of macro was undef-ed, fixed it and add a static check for it. PTAL thanks :)

return GlassBrowserFrameView::GetTopInset(restored);
}
int BraveGlassBrowserFrameView::NonClientHitTest(const gfx::Point& point) {
if (auto res = brave::NonClientHitTest(browser_view(), point);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'd better to support this for others too. brave/brave-browser#25757

if (const gfx::ImageSkia* image = tp->GetImageSkiaNamed(image_id))
width += image->width();
}
return {0, width};
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it looks so. Both seems to be DIP.

Add a tab context menu to hide window title when vertical tab strip is
enabled. When hiding window title, we can claim title area so that
users can use taller contents area.

* On Mac and Window, toolbar will take the title area.
* On Linux, title area will be as short as possible
  * can't overlay caption buttons on toolbar for now.

Also, we should make it easy to move window when hiding window title
as there's almost no non-client area. Thus, enable dragging windows
by dragging toolbar area.
Add a tab context menu to hide window title when vertical tab strip is
enabled. When hiding window title, we can claim title area so that
users can use taller contents area.

* On Mac and Window, toolbar will take the title area.
* On Linux, title area will be as short as possible
  * can't overlay caption buttons on toolbar for now.

Also, we should make it easy to move window when hiding window title
as there's almost no non-client area. Thus, enable dragging windows
by dragging toolbar area.
When TabStrip::ShouldDrawColor() returns true,
BrowserRootView will try to clip bounds tab strip. But When vertical tabstrip is enabled, converting coordinate system will fail as we have another
widget for vertical tab strip.

As we don't have to draw strokes below vertical
tab strip, returning false will be okay for our
purpose.
@sangwoo108 sangwoo108 merged commit 0645d2a into master Oct 25, 2022
@sangwoo108 sangwoo108 deleted the sko/vtab-toolbar branch October 25, 2022 09:37
@github-actions github-actions bot added this to the 1.47.x - Nightly milestone Oct 25, 2022
@sangwoo108
Copy link
Contributor Author

Thank you all for reviewing this :)

}
return {0, width};
#else
#error "not handled platform"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NOTREACHED()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
potential-layer-violation-fixes This PR touches a BUILD.gn file with check_includes=false
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Increase target of draggable chrome move up toolbar next to caption buttons when vertical tab is being used
5 participants